fix(server): stop per-session toolsets on session delete - #3884
fix(server): stop per-session toolsets on session delete#3884EronWright wants to merge 1 commit into
Conversation
A session materialised via teamloader owns a team whose toolsets may hold external resources — notably stdio MCP subprocesses. DeleteSession cancelled the runtime context but never called team.StopToolSets, so those subprocesses leaked until the server process exited; BatchDeleteSessions had the same gap. Track the per-session team on activeRuntimes and, once the session's stream has drained, call StopToolSets from both delete paths, bounding it by the originating request's deadline. Nil for attached runtimes (AttachRuntime), whose toolset lifecycle belongs to the embedder, so it is a no-op there.
aheritier
added
area/core
|
The idea is interesting @EronWright Could you rebase your PR and validate that linters and tests are passing. |
docker-agent
left a comment
docker-agent
left a comment
There was a problem hiding this comment.
Assessment: 🟡 NEEDS ATTENTION
One medium-confidence finding was identified in the new code added by this PR.
| } | ||
| }(sessionRuntime) | ||
| } | ||
| sm.runtimeSessions.Delete(sessionID) |
There was a problem hiding this comment.
[medium] BatchDeleteSessions new drain goroutine cannot be awaited via WaitStopped
The PR adds an asynchronous goroutine in BatchDeleteSessions that waits for the session stream to drain and then calls sm.stopSessionToolSets — the same teardown work that DeleteSession does. However, unlike DeleteSession (which stores the runtime in deletedSessions before returning), BatchDeleteSessions never calls sm.deletedSessions.Store(sessionID, sessionRuntime).
WaitStopped reads exclusively from deletedSessions:
rs, ok := sm.deletedSessions.Load(sessionID)
if !ok {
return nil // already cleaned up
}So a caller that does BatchDeleteSessions(...) followed by WaitStopped(sessionID, ...) will receive an immediate nil even while the new drain goroutine is still running (waiting to drain the stream and call StopToolSets). Before this PR there was nothing to wait for in BatchDeleteSessions, but now there is — and the wait contract is silently broken.
Impact: Any consumer that uses WaitStopped to synchronise on full teardown (e.g. to confirm MCP subprocesses have exited) after a batch delete will get a false-complete signal. Consider mirroring DeleteSession's deletedSessions.Store call in BatchDeleteSessions (and having the drain goroutine call deletedSessions.Delete when done), or documenting that WaitStopped is not supported after batch deletes.
| Confidence | Score |
|---|---|
| 🟡 moderate | 65/100 |
3 participants
fix(server): stop per-session toolsets on session delete
Problem
A session materialised via
teamloaderowns ateamwhose toolsets may holdexternal resources — notably stdio MCP subprocesses.
DeleteSessioncancels theruntime context but never calls
team.StopToolSets, andBatchDeleteSessionshasthe same gap (
LocalRuntime.Closeonly stops background agents;StopToolSetswasotherwise reached only via the transient
GetAgentToolCount). So a deleted session'sMCP subprocesses leak until the server process exits.
Fix
Track the per-session
teamonactiveRuntimes; once the session's stream hasdrained, call
StopToolSetsfrom both delete paths. The drain runs in a backgroundgoroutine that outlives the originating request, on a detached context
(
WithoutCancel) carrying its ownsessionDrainTimeout(5 min) budget — the samebudget already bounds the drain wait, so it now bounds the whole teardown (drain +
StopToolSets). Nil for attached runtimes (AttachRuntime), whose toolset lifecyclebelongs to the embedder — a no-op there.
Test
go test ./pkg/server/green. Verified against a multi-tenant host: the per-sessionsubprocess count returns to zero on delete and after server shutdown (previously it
stayed pinned until exit).